Method to increase performance of non-contiguously written sectors

ABSTRACT

A method of managing data in a cache upon a cache write operation includes determining a number of non-contiguously written sectors on a track in the cache and comparing the number with a threshold number. If the number exceeds the threshold number, a full background stage operation is issued to fill the non-contiguously written sectors with unmodified data from a storage medium and the full track is then destaged. A corresponding system includes a cache manager module operating on the storage subsystem. Upon a determination that a cache write operation on a track has taken place, the cache manager module determines a number of non-contiguously written sectors on the track, compares the number with a predetermined threshold number, issues a background stage operation to fill the non-contiguously written sectors with unmodified data from a storage medium if the number exceeds the threshold number, and then destages the full track.

REFERENCE TO RELATED APPLICATIONS

This Application is a continuation of U.S. patent application Ser. No. 11/549,038, now U.S. Pat. No. ______, filed on Oct. 12, 2006, the contents of which are incorporated herein by reference.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates in general to computers, and, more particularly, to a system and method to increase performance of non-contiguously written sectors in cache storage subsystems.

2. Description of the Related Art

A storage subsystem, such as the International Business Machines (IBM®) Enterprise Storage Server (ESS®), will receive Input/Output (I/O) requests directed toward an attached storage system. The attached storage system may comprise an enclosure including numerous interconnected disk drives, such as a Direct Access Storage Device (DASD), Redundant Array of Independent Disks (RAID Array), Just A Bunch of Disks (JBOD), etc. If I/O requests are received at a faster rate than they can be processed, then the storage subsystem will queue the I/O requests in a storage cache, which may comprise one or more gigabytes of volatile storage, e.g., Random Access Memory (RAM), Dynamic Random Access Memory (DRAM), etc. A copy of certain modified (write) data may also be placed in a non-volatile storage unit (NVS), such as a battery-backup volatile memory, to provide additional protection of write data in the event of a failure at the storage subsystem.

An entry is included in a Least Recently Used (LRU) list for each track in cache. A track can be staged from the storage system for cache to return to a read request. Additionally, write data for a track may be stored in cache before being transferred to the attached storage system. When additional space in cache is needed to buffer additional requested read data and modified data, tracks indicated at the LRU end of the LRU list are destaged to disk. An entry is added to the most recently used (MRU) end of the LRU list for each track added to cache. Each entry in the LRU list comprises a control block that indicates the current status of a track, the location in cache, and the location in the storage system. An additional NVS LRU list is maintained for tracks in the NVS. The cache and NVS LRU lists include entries for tracks in both NVS and cache.

Tracks written with “holes” or non-contiguously written sectors cause slow cached write performance. Holes in tracks result in cache sector misses on each write. In the worst cases, every other sector of the track becomes write modified. Destaging the tracks also results in poor disk write performance since a separate write command must be issued for each sector. On systems using RAID, the destage is further slowed down by the necessity to perform multiple drive operations for each of the single sector writes.

In light of the foregoing, a need exists for a system and method to increase performance in the event of non-contiguously written sectors on a particular track. In addition, the system and method should take advantage of existing system resources and constraints to minimize cost and complexity while maximizing efficiency in a particular implementation.

SUMMARY OF THE INVENTION

In one embodiment, the present invention is a method of managing data in a cache memory storage subsystem upon a cache write operation comprising determining a first number of non-contiguously written sectors on a track in the cache and comparing the first number with a second, predetermined threshold number, wherein, if the first number exceeds the second number, a full background stage operation is issued to fill the non-contiguously written sectors with unmodified data from a storage medium.

In another embodiment, the present invention is a system for managing data in a cache memory storage subsystem comprising a cache manager module operating on the storage subsystem, wherein, upon a determination that a cache write operation on a track has taken place, the cache manager module determines a first number of non-contiguously written sectors on the track, compares the first number with a second, predetermined threshold number, and issues a background stage operation to fill the non-contiguously written sectors with unmodified data from a storage medium if the first number exceeds the second number.

In another embodiment, the present invention is an article of manufacture including code for managing data in a cache memory storage subsystem upon a cache write operation, wherein the code is capable of causing operations to be performed, comprising: determining a first number of non-contiguously written sectors on a track in the cache, and comparing the first number with a second, predetermined threshold number, wherein, if the first number exceeds the second number, a full background stage operation is issued to fill the non-contiguously written sectors with unmodified data from a storage medium.

BRIEF DESCRIPTION OF THE DRAWINGS

In order that the advantages of the invention will be readily understood, a more particular description of the invention briefly described above will be rendered by reference to specific embodiments that are illustrated in the appended drawings. Understanding that these drawings depict only typical embodiments of the invention and are not therefore to be considered to be limiting of its scope, the invention will be described and explained with additional specificity and detail through the use of the accompanying drawings, in which:

FIG. 1 illustrates a computing environment in which aspects of the invention are implemented;

FIG. 2 illustrates example program components used to implement cache management operations in implementations where the disks in the storage system are organized into a RAID topology; and

FIG. 3 illustrates an example method of managing data in a cache storage subsystem according to the present invention.

DETAILED DESCRIPTION OF THE DRAWINGS

Some of the functional units described in this specification have been labeled as modules in order to more particularly emphasize their implementation independence. For example, a module may be implemented as a hardware circuit comprising custom VLSI circuits or gate arrays, off-the-shelf semiconductors such as logic chips, transistors, or other discrete components. A module may also be implemented in programmable hardware devices such as field programmable gate arrays, programmable array logic, programmable logic devices, or the like.

Modules may also be implemented in software for execution by various types of processors. An identified module of executable code may, for instance, comprise one or more physical or logical blocks of computer instructions which may, for instance, be organized as an object, procedure, or function. Nevertheless, the executables of an identified module need not be physically located together, but may comprise disparate instructions stored in different locations which, when joined logically together, comprise the module and achieve the stated purpose for the module.

Indeed, a module of executable code may be a single instruction, or many instructions, and may even be distributed over several different code segments, among different programs, and across several memory devices. Similarly, operational data may be identified and illustrated herein within modules, and may be embodied in any suitable form and organized within any suitable type of data structure. The operational data may be collected as a single data set, or may be distributed over different locations including over different storage devices, and may exist, at least partially, merely as electronic signals on a system or network.

Reference throughout this specification to “one embodiment,” “an embodiment,” or similar language means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the present invention. Thus, appearances of the phrases “in one embodiment,” “in an embodiment,” and similar language throughout this specification may, but do not necessarily, all refer to the same embodiment.

Reference to a signal bearing medium may take any form capable of generating a signal, causing a signal to be generated, or causing execution of a program of machine-readable instructions on a digital processing apparatus. A signal bearing medium may be embodied by a transmission line, a compact disk, digital-video disk, a magnetic tape, a Bernoulli drive, a magnetic disk, a punch card, flash memory, integrated circuits, or other digital processing apparatus memory device.

The schematic flow chart diagrams included are generally set forth as logical flow-chart diagrams. As such, the depicted order and labeled steps are indicative of one embodiment of the presented method. Other steps and methods may be conceived that correspond in function, logic, or effect to one or more steps, or portions thereof, of the illustrated method. Additionally, the format and symbols employed are provided to explain the logical steps of the method and are understood not to limit the scope of the method. Although various arrow types and line types may be employed in the flow-chart diagrams, they are understood not to limit the scope of the corresponding method. Indeed, some arrows or other connectors may be used to indicate only the logical flow of the method. For instance, an arrow may indicate a waiting or monitoring period of unspecified duration between enumerated steps of the depicted method. Additionally, the order in which a particular method occurs may or may not strictly adhere to the order of the corresponding steps shown.

Furthermore, the described features, structures, or characteristics of the invention may be combined in any suitable manner in one or more embodiments. In the following description, numerous specific details are provided, such as examples of programming, software modules, user selections, network transactions, database queries, database structures, hardware modules, hardware circuits, hardware chips, etc., to provide a thorough understanding of embodiments of the invention. One skilled in the relevant art will recognize, however, that the invention may be practiced without one or more of the specific details, or with other methods, components, materials, and so forth. In other instances, well-known structures, materials, or operations are not shown or described in detail to avoid obscuring aspects of the invention.

Turning to FIG. 1, a storage subsystem computing environment in which aspects of the present invention are implemented is depicted. A storage subsystem 2 receives I/O requests from hosts 4 a, 4 b . . . 4 n directed to tracks in a storage system 6, which comprises one or more hard disk drives 8 a, 8 b . . . 8 n. The storage system 6 and disk drives 8 a, 8 b . . . 8 n may be configured as a DASD, one or more RAID ranks, etc. The storage subsystem 2 further includes one or more central processing units (CPUs) 10 a, 10 b, 10 c . . . 10 n, a cache 12 comprising a volatile memory to store tracks, and a non-volatile storage unit (NVS) 14 in which certain dirty or modified tracks in cache are buffered. The hosts 4 a, 4 b . . . 4 n communicate I/O requests to the storage subsystem 2 via a network 16, which may comprise any network known in the art, such as a Storage Area Network (SAN), Local Area Network (LAN), Wide Area Network (WAN), the Internet, an Intranet, etc. The cache 12 may be implemented in one or more volatile memory devices and the NVS 14 implemented in one or more high-speed non-volatile storage devices, such as a battery-backed-up volatile memory. A cache manager module 18 comprises either a hardware component or process executed by one of the CPUs 10 a, 10 b . . . 10 n that manages the cache 12. A stage/destage manager module 20 comprises a software or hardware component that manages stage and destage operations.

FIG. 2 illustrates example program components used to implement cache management operations in implementations where the disks 8 a, 8 b . . . 8 n in the storage system 6 are organized into RAID ranks. FIG. 2 illustrates a cache LRU list 22 in which every track in cache 12 is listed, an NVS list 24 in which every track in the NVS 14 is listed, and one RAID Rank LRU list 26 a, 26 b . . . 26 n for each RAID rank configured in the storage system 6. The CPUs 10 a, 10 b . . . 10 n would execute threads to perform various operations. The executing threads 30 include an LRU task thread 32 that scans the cache LRU list 22 looking for entries for modified tracks that satisfy certain criteria, such as a track in a specified RAID rank, multiple executing destage threads 34 a and 34 b that are called to destage a track from cache 12 to the storage system 6, multiple executing stage threads 34 c and background stage threads 34 d that are called to stage a track from storage system 6 to cache 12 or execute a full background stage operation as will be later described, and other threads 36 performing any other storage subsystem 2 operation.

In addition, FIG. 2 illustrates a cache bit map 38, which includes a resident portion and a modified portion 40. Cache bit map 38 is maintained to assist in allocating file space for data in the cache. Modified portion 40 is a subset of resident portion 38. Bit map 38 can describe the allocation of each block or sector in a track in the cache. Modified portion 40 can be compared against resident portion 38 to determine if there are any non-contiguous sectors on a particular track, or “holes.”

FIG. 3 describes an example method 42 of managing data in accordance with the present invention. The method 42 begins (step 44) by the storage subsystem querying whether a cache write operation has been completed (step 46). The determination of whether a cache write operation has been completed can be performed by a CPU 10 or a cache manager module 18 or a similar processing component located as part of subsystem 2 or elsewhere. Cache manager module 18 essentially keeps track of the status of all tracks in cache. Cache module 18 can compare modified bit map 40 with resident bit map 38 to make a determination as to which sectors in a particular track are non-contiguous. Further, module 18 can count the number of non-contiguous instances, or holes exist in a particular track (step 48). The number of holes can be then compared with a predetermined threshold number. In one embodiment, the predetermined threshold may be six (6) instances. If the counted number of holes exceeds the predetermined threshold (step 50), the module 18 can issue a full background stage operation, causing unmodified data to be staged from a disk 8 or other storage medium in storage system 6 to fill in the holes (step 52). The method 42 then begins anew.

Reference to a “background” stage refers to an executing thread 30 which is run in the background or on a separate executing thread that the cache manager module 18 may be executing at a particular time. As a result of invoking a stage operation, all non-contiguous sectors in a particular track are filled with unmodified data. Because an affected track which has underwent a background stage operation has all sectors which are then filled, an entire image of data can be constructed when incorporating the particular data into a write command. The full track is essentially now in cache.

Following a full background stage operation, the full track can be written to disk 8 or a similar storage medium with a single write command. For example, the full track can then be destaged to disk following an LRU algorithm previously described. This replaces the necessity of having to construct a single sector write command for every other modified sector in a track not subjected to the present invention.

Again, the present invention increases host write and destage performance of modified tracks with a large number of non-contiguous sectors or holes by calculating the number of holes in the track at the completion of each cache write operation. If a large number of holes are present, a full track stage of the track is issued in the background. Following the completion of the background stage, subsequent write performance is improved because what were sector misses are now cache hits. Destage performance is also increased since the destage is now a full track write to the disks.

At the completion of a cache write operation, a count of the number of holes in the track is calculated. If the number of holes calculated on the track is greater than a predetermined threshold, a full track background stage is issued. Since the full track is now in cache, subsequent writes to the track are faster, since they are now cache hits. Destage performance is improved since the full track can either be grouped for a full stride write, or, if the track is destaged by itself, the track can be implemented using a full track write instead of a plurality of single sector writes.

Software and/or hardware to implement the method previously described, such as the described full background stage, can be created using tools currently known in the art. The implementation of the described system and method involves no significant additional expenditure of resources or additional hardware than what is already in used in many storage subsystems, making the implementation cost-effective.

Implementing and utilizing the example systems and methods as described can provide a simple, effective method of increasing performance in a computer system featuring a cache storage subsystem. While one or more embodiments of the present invention have been illustrated in detail, the skilled artisan will appreciate that modifications and adaptations to those embodiments may be made without departing from the scope of the present invention as set forth in the following claims. 

1. A method for managing data in a cache, the method comprising: identifying one or more non-contiguously written sectors in a partially filled track; performing a full background stage operation to fill the one or more non-contiguously written sectors with unmodified data from a storage medium to create a full track and destaging the full track to the storage medium.
 2. The method of claim 1, wherein identifying the one or more non-contiguously written sectors comprises: receiving, by the cache, a write operation; determining a number of non-contiguously written sectors on a track in the cache; and comparing the number of non-contiguously written sectors with a predetermined threshold number of non-contiguously written sectors.
 3. The method of claim 2, further including, prior to determining the number of non-contiguously written sectors, detecting that the write operation has taken place.
 4. The method of claim 2, wherein determining the number of non-contiguously written sectors is performed using a cache bit map that is maintained by a storage subsystem.
 5. The method of claim 4, wherein the cache bit map further includes a resident bit map and a modified bit map, the resident and modified bit maps compared to determine the number of non-contiguously written sectors on the track.
 6. The method of claim 1, wherein destaging the full track is performed with a single write command.
 7. A system for managing data in a cache memory storage subsystem, comprising: a cache manager module operating on the storage subsystem, wherein the cache manager module is configured for: identifying one or more non-contiguously written sectors in a partially filled track; performing a full background stage operation to fill the one or more non-contiguously written sectors with unmodified data from a storage medium to create a full track and destaging the full track to the storage medium.
 8. The system of claim 7, wherein, when identifying the one or more non-contiguously written sectors, the cache manager module is further configured for: receiving, by the cache, a write operation; determining a number of non-contiguously written sectors on a track in the cache; and comparing the number of non-contiguously written sectors with a predetermined threshold number of non-contiguously written sectors.
 9. The system of claim 8, wherein the cache manager module is further configured for, prior to determining the number of non-contiguously written sectors, detecting that the write operation has taken place.
 10. The system of claim 8, wherein determining the number of non-contiguously written sectors is performed using a cache bit map that is maintained by a storage subsystem.
 11. The system of claim 10, wherein the cache bit map further includes a resident bit map and a modified bit map, wherein the resident and modified bit maps are compared to determine the number of non-contiguously written sectors on the track.
 12. The system of claim 7, wherein, when destaging the full track, the cache manager module is configured for destaging the full track with a single write command.
 13. An article of manufacture including code for managing data in a cache memory storage subsystem upon a cache write operation, wherein the code, when executed by a processor, causes the processor to: identify one or more non-contiguously written sectors in a partially filled track; perform a full background stage operation to fill the one or more non-contiguously written sectors with unmodified data from a storage medium to create a full track and destage the full track to the storage medium
 14. The article of manufacture of claim 13, wherein the code for identifying the one or more non-contiguously written sectors comprises code that causes the processor to: receive, by the cache, a write operation; determine a number of non-contiguously written sectors on a track in the cache; and compare the number of non-contiguously written sectors with a predetermined threshold number of non-contiguously written sectors.
 15. The article of manufacture of claim 14, further including code that causes the processor to, previous to the step of determining the number of non-contiguously written sectors on a track in the cache, detect that the write operation has taken place.
 16. The article of manufacture of claim 14, wherein the code that causes the processor to determine the number of non-contiguously written sectors is performed using a cache bit map that is maintained by a storage subsystem.
 17. The article of manufacture of claim 16, wherein the cache bit map further includes a resident bit map and a modified bit map, the resident and modified bit maps compared to determine the number of non-contiguously written sectors on the track.
 18. The article of manufacture of claim 13, wherein destaging the full track is performed with a single write command. 